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FOREWORD 


This  document  is  a  Technical  Task  Report  for  Contract 
No.  K00014-73-C“0131  for  the  Office  of  Naval  Research.  The 
report  summarizes  the  work  performed  in  fulfilling  contract 
objectives. 

Ocean  Data  Systems,  Znc.  is  indebted  to  Mr.  R.  Plum, 

MASWSPO  for  his  efforts  in  securing  the  data  and  information 
required  in  the  performance  of  the  task  effort.  Additionally, 
OD5I  wishes  to  acknowledge  the  support  and  cooperation  of 
Messrs.  George  Drown  and  Dick  D'Urso  of  the  Naval  Underwater 
Systems  Center,  Messrs.  Paul  Tiedman  and  Barry  Chapman  of  the 
Naval  Ship  Systems  Command,  Messrs.  Donald  Mudd  and  Robert 
Lawrence  of  the  Naval  Electric  Laboratory  Center,  Dr.  P.  R. 

Tatro  and  Mr.  C.  W.  Spofford  of  the  Acoustic  Environment  Support 
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Detachment,  and  Messrs.  Tom  Russell  and  Jerry  Bradshaw  of 
Raytheon. 


ABSTRACT 


This  report  analyzes  the  SIMAS  and  FLIT  acoustic  performance 
systems,  under  development  at  the  Naval  Underwater  Systems  Center, 
Newport,  Rhode  Island,  focusing  on  the  degree  of  commonality  of 
conceptual  approach  and  compatibility  of  computed  results. 

Where  an  operational  basis  for  comparison  is  required,  reference 
is  to  the  ICAPS  system  currently  installed  aboard  the  USS  Kitty 
Hawk  (CV-63)  and  to  the  Navy  Tactical  Data  System  (NTDS) .  It 
is  concluded  that  the  constraints  imposed  by  existing  on-board 
computer  environments  and  associated  administrative  procedures 
preclude  the  attainment  of  an  at-sea  SIMAS  capability  within  a 
reasonably  short  timeframe,  except  where  extra  Q-20  computers 
are  available  outside  the  NTDS  system,  and  that  external  design 
constraints  imposed  on  the  FLIT  developers  have  precluded  the 
incorporation  of  compatible  transmission  loss  physics  irfto  this 
model. 
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INTRODUCTION 


There  are  currently  a  large  number  of  acoustic  per¬ 
formance  prediction  systems,  both  shore-based  and  at-sea, 
which  are  in  various  stages  of  development  and  operational 
use.  Many  of  these  systems  have  structural  similarities 
which  are  a  direct  consequence  of  their  related  overall 
objectives  and  the  nature  of  the  common  problems  being 
solved.  Also,  however,  many  differences  exist  among  these 
systems . 

Some  of  the  differences  among  the  systems  are  a  direct 
consequece  of  the  differences  in  the  environments  within 
which  each  of  the  systems  is  to  operate  or  for  reasons 
of  historical  development.  Other  differences  exist  be¬ 
cause  different  methods  are  used  to  calculate  intermediate 

« 

values  such  as  transmission  loss  or  because  some  of  the 
systems  consider  more  variables  in  their  calculations  than 
others  which  may  choose  to  estimate  the  effects  of  such 
variables  by  using  averages  or  simple  distributions. 

Further,  differences  may  also  occur  because  of  variations 
in  the  sources  or  types  of  input  data  and  whether  that 
data  has  been  pre-processed  in  any  way  such  as  elimination 
of  exceptional  points,  smoothing,  or  by  subjecting  such 
input  data  to  range  tests  and  error  detection. 

In  the  course  of  the  task  effort  reported  herein,  the 
SIMAS  and  FLIT  at-sea  performance  prediction  systems  were 
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analyzed  from  the  viewpoint  of  ascertaining  the  degree  to  which 
a  commonality  of  conceptual  approach  and  compatibility  of 
comparable  computed  results  could  be  fostered.  The  systems 
are  currently  under  development  at  the  Naval  Underwater  Systems 
Center  (NUSC) ,  Newport,  Rhode  Island. 

The  primary  emphasis  was  placed  on  the  determination  of 
the  computational  and  evnironmental  resources  required,  and  on 
the  computational  and  data  utilization  techniques  employed, and 
the  implications  of  these  factors  for  standardization  of  Navy 
acoustic  performance  prediction  systems.  ODSI's  role  in  the 
performance  of  these  analyses  was  primarily  focused  towards 
programmatic  implementation  rather  than  towards  the  physics 
modeled  by  the  systems.  Navy  organizations  such  as  the  Acoustic 
Environmental  Support  Division  were  to  assess  the  acoustic  and 
environmental  goodness  of  their  constituent  elements  for  the 
Government's  Scientific  Officer. 

Section  II  of  this  report  presents  the  ODSI  review  of 
FLIT  based  on  existing  documentation  of  the  system;  Appendix  A 
presents  a  memorandum  prepared  by  AESD  addressing  the  FLIT 
Program.  Sections  III  through  VI  outline  the  objectives  and 
status  of  SIMAS,  its  compatibility  with  existing  systems  and 
prospects  for  an  at-sea  operational  capability.  Material  con¬ 
tained  in  these  sections  has  been  reported  on  in  earlier  ODSI 
Technical  Task  Reports. 


II.  REVIEW  OF  THE  FLIT  SYSTEM 

The  FLIT  effort  has  been  directed  toward  the  determin¬ 
ation  of  the  compatibility  of  this  system  with  other  existing 
Navy  propagation  and  performance  estimation  models.  As  a 
first  step  in  this  effort,  a  review  of  the  existing  documenta¬ 
tion  of  FLIT  was  initiated.  The  Scientific  Officer  assigned 
the  review  of  the  acoustic  and  sonar  system  performance  con¬ 
siderations  to  the  Acoustic  Environmental  Support  Detachment 
(AESD) ,  while  Ocean  Data  Systems,  Inc.  was  directed  to  review 
the  programming  and  systems  analysis  aspects.  This  section 
of  this  task  report  summarizes  the  results  of  the  ODSI  review. 

The  specific  document  made  available  for  assess¬ 
ment  is  the  "MPS  Ray  Path  Trace  Submode  Design  and  Performance 
Specifications",  which  presents  a  detailed  description  of 
the  objectives  of  each  of  eleven  software  modules  of  MPS. 

These  modules  are  organized  into  four  broad  categories  as 
follows : 


System  Monitor  and  Control 

•  PSPS,  the  overall  MPS  software  supervisor 

•  RTSM,  which  controls  the  selection  of  MPS  modes 

Data  Entry  and  Display 

•  RTDE,  controlling  the  interactive  data  entry 

from  the  system  console 

•  RTVP ,  handling  the  entry  and  display  of  the 

sound  velocity  profile 
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•  RTTU,  handling  the  entry  of  data  for  table 

updating 

Ray  Tracing  and  Display 

•  RTRD,  displaying  the  ray  paths  traced  by  UPS 

•  RTRP,  which  generates  the  ray  paths  to  be 

displayed 

•  RTRC,  which  performs  the  actual  ray  trace  for 

a  single  ray  cycle 

Functional  Evaluation 

•  RTCT,  which  computes  water  temperature  as  a 

function  of  sonic  velocity,  salinity,  depth, 
and  latitude 

•  RTCV,  which  computes  sonic  velocity  as  a 

function  of  temperature,  salinity,  depth, 
and  latitude 

•  RTBL,  which  computes  bottom-bounce  losses  as 

a  function  of  incidence  angle  and  bottom  class 

•  RTSL,  which  computes  surface-reflection  losses 

as  a  function  of  frequency  and  sea  state 

Before  commenting  individually  on  these  models,  a 
word  about  the  overall  design  is  in  order.  The  software  design 
appears  to  be  well  thought-out  and  modularized  into  manageable 
routines  whose  interactions  can  be  kept  to  a  minimum,  thus 
easing  the  software  programming,  checkout,  and  maintenance 
tasks.  With  one  significant  exception  —  the  lack  of  introductory 
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material  spelling  out  the  software  structure,  hardware  con¬ 
straints,  nomenclature  employed  —  the  documentation  is 
detailed,  comprehensive  and  well-organized.  Perhaps  such 
an  introduction  exists  elsewhere;  if  so,  it  should  be  included 
whenever  the  current  material  is  distributed;  if  not,  one  should 
be  prepared  to  ease  the  burden  of  becoming  acquainted  with 
the  material  presented. 

The  flowcharts  are  complete,  within  each  module, 
written  at  an  appropriate  level  of  detail.  Again,  however,  a 
significant  lack  is  that  of  an  over-all,  high-level  flow  showing 
the  interactions  of  each  of  the  modules,  and  how  specific 
hardware  features  —  interrupts,  data  entry  keys,  shaft 
encoders,  etc.  —  are  interfaced.  Similarly,  the  means  by 
which  data  values  are  passed  between  modules  is  not  detailed; 
this  is  a  function  of  the  programming  language  used  and  the 
software  system  functions  available  to  support  the  implementa¬ 
tion  of  the  language,  neither  of  which  are  referenced  in  the 
documentation . 

Each  of  the  modules  is  described  in  a  "Design 
Specification"  section  of  the  document.  Additionally,  for 
those  routines  which  are  on  the  "critical-path"  with  regard  to 
processing  accuracy,  time,  and/or  storage  requirements, 
"Performance  Specifications"  are  included.  This  is  a  vital 
step  often  overlooked  in  system  design  and  is  to  be  commended. 
However,  we  have  no  way  of  determining  whether  or  not  the 
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hardware  and  software  implementation  allows  these  specifica¬ 
tions  to  be  met  in  actual  practice,  and  can  only  assume  that 
this  will  be  the  case. 

With  regard  to  the  System  Monitor  and  Control  Modules 
there  is  little  to  be  said,  as  these  are  highly  hardware 
dependent,  and,  at  the  same  time,  should  be  almost  completely 
transparent  to  the  FLIT/MPS  user  -  he  should  be  unaware  of 
their  existence.  It  is  assumed  that  these  modules  handle 
the  inevitable  hardware  failures  in  a  "graceful"  manner;  this 
means  full  automatic  recovery  in  the  best  of  cases,  and  in 
any  case,  to  provide  a  convenient  restart  procedure  along  with 
informative  diagnostic  capability. 

The  Data  Entry  and  Display  category  is  perhaps  the 
most  critical  with  respect  to  both  design  and  performance  of 
the  system.  This  is  because  MPS  is  primarily  an  on-line,  inter 
active,  man-machine  system.  It  is  vital  that  this  interface 
put  as  few  burdens  on  the  operator  as  possible,  and,  according 
to  the  specifications,  this  is  indeed  the  case  so  long  as  the 
operator  is  skilled. 

What  is  not  clear,  however,  is  the  response  of  the 
system  to  well  intentioned  but  inadvertent  errors  on  the  part 
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of  the  operator.  In  a  well-designed  interactive  system,  the 
operator  will  work  in  close  "rapport"  with  the  input  and  display 
devices,  and,  working  rapidly,  will  often  make  minor  mistakes 
which  are  "almost"  right,  but  which,  in  a  poorly  designed 
system,  can  lead  to  disastrous  results.  An  example  will 
illustrate.  The  operator  must,  of  course,  be  given  a  "clear 
the  decks  and  start  all  over"  capability.  The  interactive 
system  must  make  sure  that  this  command  is  r ea 1 1 y  meant  by 
the  operator,  and  not  just  an  inadvertent  action  -  otherwise, 
much  work  may  be  lost,  with  great  operator  frustration. 

Placement  of  the  key  on  the  keyboard  (or  virtual  key  on  a 
light-pen/CRT)  should  isolate  this  function  as  much  as  possible, 
of  course;  but  the  software  must  also  respond  with  a  "Do 
you  really  want  to  do  that"  indication  in  such  a  situation,  if 
a  smooth  man-machine  interaction  is  to  be  achieved.  A  general 
rule  is  that,  on  any  error,  the  operator  should  be  able  to 
"back  up"  and  try  again,  and  that  the  "backing-up"  should  be 
limited,  whenever  possible,  to  the  point  immediately  preceding 
the  error  condition. 

Errors  of  this  kind  often  arise  when  an  interactive 
system  operates  in  several  "modes",  with  nearly  identical 
operator  actions  having  dissimilar  effects  in  each  of  these 
modes.  For  smooth  interaction,  therefore,  it  is  essential 
that:  1)  the  number  of  modes  be  held  to  a  minimum;  2)  that 

the  operator  be  clearly  aware  of  the  current  system  mode; 

3)  the  operator  bo  able  to  change  nodes  at  will;  and  4)  that 
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identical  operators  have  identical  or  corresponding  actions  in 
each  mode  whenever  possible,  without  ambiguity. 

The  above  state  of  affairs,  however  vital,  is  not 
easy  to  achieve,  and  cannot  be  determined  by  an  examination  of 
the  software  design  and  performance  specifications,  but  only 
by  actual  on-line  experience.  It  is  hoped  that  the  project 
development  schedule  allows  for  the  incorporation  of  these 
features  during  systems  checkout  and  acceptance  testing. 

With  regard  to  the  Data  Entry  category,  the  following 
specifics  are  felt  to  be  relevant: 

•  While  both  the  working  and  system  velocity  profiles 

may  be  displayed  simultaneously,  it  is  unclear 
whether  or  not  a  similar  capability  exists  to 

i 

display  the  shallow  (0-200  feet,  say)  portion 
of  the  profile  on  an  expanded  scale  simultaneously 
with  the  complete  profile.  The  greatest  "structure" 
is  often  in  this  shallow  portion,  and,  a  linear 
scale  to  full  bottom  depth,  is  quite  inappropriate. 

•  What  is  the  effect  on  the  display  when  the 

allowable  (vertical)  density  of  svp  points  is 
exceeded? 

•  Are  provisions  to  be  made  for  metric  as  well  as 

English  units? 
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•  Is  any  interface  with  a  library  of  previously 

cataloged  SVP  data  possible?  Must  all  data 
be  entered  via  the  terminal  by  the  operator? 

Are  there  provisions  for  storing  this  data  on 
other  than  a  transitory  basis? 

•  Is  it  possible  to  interrupt  the  SVP  processing 

to  examine  and  change  table  update  parameters 
and  return  to  the  same  point  in  SVI>  processing? 

•  Is  it  possible  to  have  incompatible  SVP  and  table 

update  data?  (E.g.,  bottom  depth,  deep  ocean 
temperature,  etc.) 

•  Are  alerts  displayed  only  in  a  certain  display 

mode,  or  is  a  separate  hardware  display  unit 
used? 

•  Must  the  source  and  receiver  depths  used  in  the 

ray-tracing  modules  be  inserted  as  explicit 
points  in  the  profile?  Is  this  done  automatically 
If  so,  how  is  the  interpolation  made?  If  not, 
how  is  the  operator  requested  to  do  so? 

•  Are  future  provisions  envisioned  which  will  allow 

automatic  corrections  to  profile  depths  and 
velocities  to  account  for  spherical  earth 
geometries? 

A  final  point  can  only  be  determined  by  operational 
evaluation,  namely,  do  the  specified  system  functions  provide 


an  adequate  base,  or  must  more  functions  be  implemented  in 
response  to  operator  feedback  after  initial  system  operation. 
Again,  it  is  to  be  hoped  that  development  time  is  available 
for  this  if  necessary. 

The  third  category  of  modules  in  the  MPS  system  are 
those  implementing  the  Ray  Tracing  and  Display  Functions.  It 
is  here  that  the  greatest  opportunity  for  compatibility  or 
incompatibility  with  other  systems  and  the  state-of-the-art 
exists.  It  can  be  stated  at  the  outset  that  the  ray-tracing 
physics  employed  does  accurately  implement.  Snell's  Law  for  a 
layered  medium,  using  standard  equations  and  techniques.  The 
relation  between  ray  tracing  and  accurate  estimation  of  trans¬ 
mission  loss  is  quite  another  matter  however  —  witness  the 
widely  differing  approaches  of  the  many  available  ray-tracing 
transmission  loss  models.  And,  in  a  similar  manner,  the 
relationship  of  transmission  loss  estimates  to  performance 
prediction  for  active  and  passive  detection  systems  presents 
a  complex  problem  in  modeling  techniques.  A  separate,  detailed 
evaluation  of  this  area  of  KPS  remains  to  be  made;  however,  a 
number  of  comments  follow,  which  are  based  on  preliminary 
examination  of  the  specifications.  These  are  based  on  a 
comparison  of  the  functions  of  MPS  with  those  of  FACT,  the 
Navy  Interim  standard  transmission  loss  model  for  a  single¬ 
profile,  flat-bottom  ocean  environment. 

•  Acoustic  transmission  loss  is  estimated  along  a 
single  ray  path  only;  the  effects  of  multiple 
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ray  paths  from  source  to  receiver  are  ignored. 
There  seems  to  be  no  provision  for  combining 
arrivals  over  a  range  of  ray  angles  to  obtain 
an  overall  transmission  loss  estimate.  This 
seems  to  be  a  significant  oversight  in  light 
of  the  "variable  beam"  capability  which  presumably 
is  useful  for  matching  sonar  receiver  beam  widths. 

•  This  single-path  transmission  loss  is  compared 

with  a  single  Figure-of-Merit  for  a  sonar 
system.  It  is  unclear  how  this  Figure-of-Merit 
is  input  (i.e. ,  what  drives  the  related  shaft 
encoder) ,  and  how  this  varies  with  platform 
speed  (self-noise)  and  background  noise,  which 
itself  is  a  function  of  the  transmission  loss  in 
the  medium  being  modeled.  The  distinction 
between  active  and  passive  systems  is  unclear. 

•  Because  of  the  effects  introduced  by  a  linearly- 

segmented  profile  as  opposed  to  a  smooth  sound- 
velocity  profile,  the  process  used  to  select 
the  rays  to  be  traced  is  critical.  The  segmented 
profile  introduces  false  caustics  into  certain 
rays,  and  these  must  be  avoided  to  prevent  the 
expression  used  for  transmission  loss  from 
becoming  indeterminate.  Similarly,  the  rays 
defining  true  caustics  must  be  selected  and 
retained . 
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•  All  transmission  loss  estimation  formulas  ignore 

the  effects  of  smooth  and  cusped  caustic 
fields;  it  is  usually  in  these  regions  where 
the  most  "interesting"  transmission  loss  effects 
occur. 

•  No  provision  has  been  made  for  including  coherency 

effects  for  source  and/or  receiver  depths  close 
to  the  surface;  these  geometries  lead  to  two 
or  four  nearly  parallel  transmission  paths  along 
which  interference  effects  become  significant. 

•  The  effects  of  frequency  are  confined  to  surface, 

bottom,  and  volume  absorbtion  effects. 

•  No  treatment  for  half-channel  and/or  axis-to-axis 

transmission  has  been  included;  these  cases 
require  the  combination  of  many  paths  from  the 
source  to  receiver  for  accurate  transmission 
loss  estimation. 

•  No  provision  for  incorporating  low-frequency 

cut-off  effects  has  been  included. 

•  No  provision  for  treatment  of  surface-duct 

transmission  has  been  included. 

•  The  only  transmission-loss  display  is  the  two- 

level  brightness  along  a  ray  path  indicating 
whether  or  not  the  Figure-of-Merit  has  been 
exceeded.  In  view  of  the  way  in  which  trans¬ 
mission  loss  is  estimated,  this  indeed  may  be 
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appropriate.  It  would  seem  more  useful, 
however,  to  display  a  complete  transmission 
loss  graph  as  a  function  of  range,  with  a 
horizontal  line  overlaid  to  indicate  the 
Figure-of -Merit . 

It  should  be  noted  that  nearly  all  of  the  above 
comments  relate  to  the  incorporation  of  additional  sophistica¬ 
tion  into  the  process  of  going  from  simple  ray-tracing  to 
transmission  loss  estimation,  and  that  all  can  require  signi¬ 
ficant  additional  program  development.  This,  in  turn,  will 
make  adc itional  demands  on  the  implementing  hardware,  requiring 
more  computation  time  and  core  storage.  Since  no  information 
whatever  has  been  made  available  as  to  the  constraints  on  these 
resources  imposed  by  the  available  hardware,  and  by  the  response¬ 
time  characteristics  which  must  be  achieved,  these  may  well  be 
the  limiting  factors  in  determining  the  accuracy  of  system 
performance  estimations. 

Of  the  final  category  of  modules,  Functional  Evalua¬ 
tion,  only  a  few  comments  are  in  order. 

•  The  relationship  of  the  formulas  for  profile 
temperature  and  sonic  velocity  to  those  of 
the  widely-used  Wilson's  equation  has  not  been 
examined?  it  is  not  known  if  any  significant 
differences  exist. 
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•  The  relationship  of  the  expressions  for  bottom** 

bounce  losses  to  those  of  the  widely-used  FNWC 
tables  and  formulas  has  not  been  examined; 
again,  it  is  unknown  if  any  significant 
differences  exist. 

•  The  formulas  used  for  surface-reflection  estima¬ 

tion  introduce  a  discontinuity  of  about  .3  dB; 
it  has  not  been  determined  if  this  figure  is 
signif icant . 

In  summary,  a  number  of  comments  have  been  made  as  a 
result  of  a  review,  from  a  systems  analysis  and  programming 
viewpoint,  of  the  Design  and  Performance  Specifications  for 
the  MPS  Ray  Path  Trace  Submode  of  FLIT.  As  in  any  highly 
interactive  system,  definitive  evaluation  must  be  based  on 
observations  of  the  actual  performance  of  the  system  in  its 
intended  environment,  with  special  emphasis  on  the  man-machine 
interface.  This  clearly  has  not  been  possible  in  the  present 
case.  Similarly,  a  definitive  evaluation  of  the  applicability 
of  the  physical  model  employed  depends  critically  on  the  uses 
which  the  model  results  are  to  serve.  Again,  this  determination 
can  be  made  only  by  evaluation  of  the  system  by  persons  with 
experience  in  acoustic  modeling  situations. 

The  foregoing  considerations  lead  us  to  conclude  that 
unless  the  previously  referenced  review  of  the  physics  of  the 
FLIT  system  indicates  the  need  for  new  developments  (directed. 


for  example,  at  enhancing  the  transmission  loss  estimation) 
no  change  to  the  current  FLIT  system  would  seem  to  be  either 
necessary  or  advisable  at  this  time,  certainly  not  as  a 
result  of  any  programmatic  implementation  considerations. 


III.  OBJECTIVES  OF  SIMAS 


The  SIMAS  —  Sonar  In-Situ  Mode  Assessment  System  —  model 
is  a  set  of  programs  designed  to  automate  the  sonar  watch 
supervisor’s  task  by  estimating  acoustic  path  availability  and 
detection  ranges,  and  by  providing  recommended  equipment  settings, 
primarily  for  the  SQS-26  sonar.  The  system  was  originally 
implemented  at  the  Naval  Underwater  Systems  Center  (NUSC) , 

Newport,  Rhode  Island.  Additional  development  of  SIMAS  has 
been  performed  at  the  Naval  Electronics  Laboratory  Center  (NELC) , 
San  Diego,  California. 

As  part  of  an  overall  task  of  investigating  the  degree 
to  which  commonality  of  conceptual  approach  and  compatibility 
could  be  achieved  among  a  number  of  existing  at-sea  performance 
prediction  systems,  Ocean  Data  Systems,  Inc.  (ODSI)  has  attempted 
to  determine  the  feasibility  of  providing  onboard  SIMAS  capability 
for  fleet  operations  in  a  reasonably  short  time  frame  (6  months) , 
and  to  determine  how  this  effort  could  best  be  undertaken. 

A  primary  objective  has  been  to  insure  that  such  a  capability 
employs  the  most  accurate  methods  of  computation,  consistent 
with  the  constraints  of  existing  computational  resources,  and 
uses  the  best  data  available,  thereby  achieving  a  step  towards 
further  standardization  of  Navy  acoustic  performance  systems. 

At  a  very  broad  level  of  detail,  SIMAS  can  be  considered 
as  consisting  of  three  separate  but  interrelated  components: 


III-l 


•  Environment.  This  component  combines  in-situ 
bathythermographic  data  with  historical  data  as 
the  basis  for  generating  a  sound-velocity  profile 
from  surface  to  bottom. 

•  Range  Prediction.  On  the  basis  of  the  environmental 
profile,  signal  excess  values  are  computed  as  a 
function  of  range  for  direct-path  transmission, 

and  as  a  function  of  two-way  travel  time  for  bottom- 
bounce  and  convergence  zone  modes. 

•  Equipment  Optimization.  Using  the  computed  signal 
excess  values,  the  applicability  and  utility  are 
estimated  for  each  transmission  mode,  and,  where 
practical,  equipment  switch  settings  are  determined 
which  will  give  the  best  performance  from  the  sonar 
system  being  used. 

It  should  be  noted  that  the  first  two  components  must,  in 
general  terms,  be  provided  for  any  acoustic  performance  estima¬ 
tion  system,  and  that  it  is  these  areas  that  commonality  with 
other  systems  is  most  likely  to  be  achieved.  For  example,  the 
ICAPS  system  developed  by  NAVOCEANO  currently  provides  common 
environmental  processes  for  at  least  three  acoustic  models, 
and  one  of  these,  SHARPS,  computes  signal  excess  values  as  a 
step  in  estimating  expected  detection  ranges  for  sonar  systems. 
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Only  the  third  component,  that  which  provides  sonar 
"knob  settings",  is  peculiarly  the  function  of  the  SIMAS 
system. 

In  order  to  provide  an  at-sea  SIMAS  capability  at  the 
earliest  possible  date,  some  means  must  be  found  to  integrate 
the  existing  on-shore  programs  into  existing  on-board  computer 
systems,  while  balancing  the  conflicting  requirements  of  minimum 
development  time,  maximum  compatibility  and  commonality,  and 
constraints  imposed  by  programming  language  and  hardware  com¬ 
putational  resources. 

Subsequent  sections  of  this  report  discuss  the  currently 
available  versions  of  SIMAS  and  the  at-sea  operating  environ¬ 
ment,  and  the  prospects  for  timely  introduction  of  an  operational 
SIMAS  model  to  the  fleet. 
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IV. 


CURRENT  STATUS  OF  SIMAS 


There  currently  exist  three  separate  versions  of  SIMAS 
which  provide  the  basic  functions  outlined  in  Section  I.  For 
convenience,  the  remainder  of  this  report  will  refer  to  these 
by  reference  to  the  primary  computer  system  on  which  they  were 
implemented.  It  should  be  kept  in  mind,  however,  that  this 
distinction  does  not  necessarily  reflect  their  most  important 
differences,  as  the  following  brief  descriptions  will  make 
clear : 


1108 .  This  version  of  SIMAS  was  developed  at  NUSC. 

The  program  is  written  entirely  in  FORTRAN,  and  can  thus  be 
modified  with  relative  ease  to  work  with  and  take  advantage 
of  commonality  and/or  overlap  with  other  acoustic  prediction 
systems  modelled  in  FORTRAN.  Additionally,  the  program  can  be 
adapted  to  run  on  hardware  configurations  which  have  sufficient 
capacity  to  support  a  FORTRAN  compiler.  This  freedom  is  not 
without  limitations,  however,  as  the  resulting  running  time  may 
increase  exorbitantly  if  the  conversion  is  to  a  mini-computer 
in  which  floating  point  arithmetic  is  performed  in  software 
rather  than  in  hardware. 

PDP-11 .  This  mini-computer  version  of  SIMAS  was  also 
produced  by  NUSC,  and  adds  to  the  basic  functions  of  the 
1108  version  the  capability  to  monitor  background  acoustic 
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noise,  on  an  in-situ  basis.  The  results  are  compared  with 
predicted  noise  values  to  facilitate  decisions  regarding  the 
validity  of  the  detection  forecasts.  This  capability,  not 
readily  if  at  all  obtainable  in  a  standard  FORTRAN  environment, 
is  felt  essential  to  high-reliability  SIMAS  operation  and 
should  ultimately  be  incorporated  in  any  operational  version 
of  SIMAS. 

Q-20.  The  NELC  version  of  SIMAS  was  developed  with  the 
explicit  goal  of  operation  within  the  Naval  Tactical  Data  System 
(NTDS)  environment.  It  was  produced  from  the  1108  version  by 
direct  conversion  to  642B  (Q-20)  machine  language,  replacing 
floating  with  fixed  point  arithmetic.  To  satisfy  the  require¬ 
ments  imposed  by  the  NTDS  systems,  it  was  necessary  to  introduce 
transfers  to  the  NTDS  operating  system  monitor  at  intervals  not 
exceeding  35  milliseconds.  Nevertheless,  this  version  is  not 
directly  compatible  with  at-sea  NTDS  hardware:  The  NELC  system 
is  equipped  with  a  prototype  mass  memory  instead  of  the  operational 
Dynamic  Module  Replacement. 

The  three  versions  of  SIMAS  identified  above  are  ostensibly 
identical  in  their  functional  capability  and  performance;  the 
sole  exception  being  that  neither  the  1108  nor  the  Q-20  versions 
provide  the  background  noise  monitoring  feature  available 
through  the  PDP-11  version.  Additional  incompatibilities  may 
arise  in  the  case  of  the  Q-20  version:  In  the  limited  time 
imposed  by  available  funding,  NELC  was  only  able  to  verify  the 
operation  of  its  version  against  the  single  test  case  with  data  and 
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expected  intermediate  and  final  results  supplied  by  NUSC. 
Considerably  more  testing  would  be  required  to  ensure  the 
validity  of  the  internal  scaling  employed  and  computational 
accuracy  of  the  functional  subroutines  over  the  full  range  of 
expected  input  values. 

None  of  the  three  systems  are  currently  operational  in  the 
sense  of  being  regularly  executed  on  a  routine  basis  for  the 
purpose  of  acoustic  prediction  in  a  "live"  environment.  Any 
or  all,  however,  are  potential  candidates  for  providing  such 
an  operational  capability  in  the  near  future. 
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COMPATIBILITY  WITH  EXISTING  SYSTEMS 


In  order  to  maintain  compatability  with  existing  at-sea 
acoustic  models  -  in  particular  with  ICAPS  {Integrated  Carrier 
Acoustic  Prediction  System)  -  common  functions  should  ideally  be 
performed  by  the  same,  or  in  any  case  identical,  program 
segments.  Comparing  SIMAS  with  the  models  combined  in  ICAPS, 
this  potential  exists  with  regard  to  both  the  environmental 
and  range  prediction  sections.  Primarily  for  historical  reasons, 
each  of  the  ICAPS  models,  written  in  FORTRAN,  accepts  as  input 
a  complete  profile  consisting  of  depth-temperature-salinity 
triplets,  and  uses  identical  sub-programs  to  convert  these  to 
a  sound  velocity  profile  by  the  application  of  Wilson's  equation. 
By  the  same  means,  SIMAS  could  accept  identical  inputs  from  the 
environmental  section  of  ICAPS  and  likewise  apply  Wilson's  equa¬ 
tion.  As  ICAPS  includes  a  procedure  for  referencing  a  large 
data  file  of  historical  profile  information,  this  would  result 
in  a  significant  enhancement  of  the  SIMAS  environmental  section. 
For  the  1108  FORTRAN  version,  the  modification  would  be  quite 
easy;  however,  the  difficulties  which  might  be  encountered  with 
the  PDP-11  and  Q-20  versions  cannot  be  immediately  determined. 

The  situation  is  much  less  clear  with  respect  to  the  signal 
excess  -  range  prediction  sections,  particularly  in  light  of 
the  relationship  of  this  section  with  the  equipment  optimization 
section  in  SIMAS.  The  active  performance  section  of  ICAPS  is 
SHARPS  (Ship-Hel icoptcr  Acoustic  Range  Prediction  System), 


(again  written  in  FORTRAN) .  The  signal  excess  sections  of 
SHARPS  and  SIMAS  differ  in  two  very  significant  ways: 

First,  the  SIMAS  optimization  capability  deals  with  bottom 
bounce  and  convergence  zone  modes  and  investigates  the  signal 
excess  function  for  each  of  the  eight  beam  patterns.  The  beam 
patterns  are  an  essential  element  of  the  optimization  process. 

In  calculating  signal  excess,  however,  SHARPS  uses  analytical 
approximation  in  lieu  of  representing  discrete  beam  patterns. 

Second,  the  signal  excess  function  in  SIMAS  is  evaluated 
at  0.5  second  intervals  of  the  two-way  travel  time.  SHARPS, 
on  the  other  hand,  evaluates  the  signal  excess  function  on  the 
basis  of  starting  angle  selections.  A  minimum  and  a  maximum 
starting  angle  are  determined  and  the  angle  increment  for 
successive  signal  excess  evaluations  are  computed  as  a  fixed 
division  of  this  angular  range.  If  the  horizontal  range  incre¬ 
ment  resulting  from  two  successive  starting  angles  increases 
beyond  some  threshold,  the  angular  increment  is  reduced.  The 
significant  effect  of  this  technique  is  that  successive  evalua¬ 
tions  of  the  signal  excess  function  do  not  represent  linear 
increments  in  any  independent  variable,  thereby  resulting  in  a 
more  complex  determination  of  the  integral  of  the  signal  excess 
function  over  a  fixed  length  but  moving  "window"  than  was 
previously  the  case. 
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In  the  active  area,  these  two  considerations  dominate, 
making  it  unlikely  that  compatibility  can  be  easily  achieved; 
the  considerations  of  FORTRAN  versus  machine  language  remain  as 
before.  In  the  ideal  situation,  of  course,  identical  program 
modules  would  be  called  by  both  SHARPS  and  SIMAS  to  compute  the 
signal  excess  values  as  required.  This  however,  would  involve 
an  extensive  development  effort,  and  is  not  applicable  to  the 
present  discussion. 
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PROSPECTS  FOR  AT-SEA  SIMAS 


It  is  clear  that  the  most  desirable  operational  mode  for 
SIMAS  would  be  as  an  integral  component  of  the  Naval  Tactical 
Data  System  (NTDS) .  This  integration  is  subject  to  a  number  of 
constraints,  imposed  both  by  hardware  considerations  and  by  the 
standard  NTDS  administrative  procedures. 

Originally,  NTDS  was  designed  as  a  single  processor  system, 
with  each  computer  complex  containing  32,000  words  of  core 
memory,  30  bits  in  length,  with  no  hardware  floating  point 
capability.  However,  as  demands  on  the  NTDS  grew,  additional 
processors  were  added  to  meet  these  needs,  so  that  ships  v?ith 
NTDS  aboard  now  can  have  anywhere  from  one  to  four  processors 
linked  together.  The  overhead  associated  with  linking  computers 
grows  as  their  number  increases,  however,  and  the  law  of  diminish¬ 
ing  returns  sets  four  processors  as  a  practical  upper  limit  to 
this  mode  of  operation.  Additional  capability  is  achieved  by 
the  addition  of  the  Dynamic  Memory  Replacement  (DMR)  feature 
which  permits  program  segments  of  up  to  20K  in  length  to  be 
kept  on  magnetic  tape  and  automatically  called  into  core  for 
execution  as  required.  DMR  is  only  available  in  NTDS  installa¬ 
tions  having  two  or  more  processors. 

For  any  new  program  to  become  an  official  part  of  NTDS, 
therefore,  it  must  be  designed  to  work  with  the  DMR  feature, 
at  least  until  late  in  calendar  year  1975,  at  which  time  a 
solid-state  mass  memory  will  start  to  appear  in  the  fleet. 
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Administrative  constraints  are  imposed  by  the  Fleet  Combat 
Directions  Systems  Support  Activity  (FCDSSA) .  This  organization 
has  the  responsibility  for  the  installation  and  maintenance  of 
all  programs  that  are  to  be  part  of  NTDS.  Before  any  program 
will  be  accepted  by  FCDSSA  for  distribution  to  the  fleet,  it 
must  be  supported  by  very  extensive  documentation,  wirtten  to 
FCDSSA  standards.  In  addition,  the  program  must  be  written 
in  either  the  CS-1  or  CMS-2  languages  for  the  Q-20  computer. 

Once  a  program  has  been  accepted,  it  is  tailored  by  FCDSSA  for 
each  individual  ship  on  which  it  is  to  operate,  in  order  to 
account  for  hardware  differences  both  within  an  NTDS  facility 
itself  (processor  configurations,  available  input-output  equip¬ 
ment,  display  devices,  etc.)  and  elsewhere  on  the  ship  (sensors, 
weapons  systems,  etc.).  FCDSSA  thus  has  a  continual  program  of 
preparing  systems  for  new  ships,  and  for  updating  existing  on¬ 
board  systems  to  incorporate  new  capabilities  and  accommodate 
equipment  changes.  This  involves  an  extensive  scheduling  process 
to  mesh  with  ship  availability  and  hardware  installation  dates, 
and  thus  there  is  a  nominal  lead  time  of  about  18  month  from  the 
time  a  program  is  accepted  by  FCDSSA  to  the  first  appearance  of 
the  program  in  the  fleet. 

In  order  for  SIMAS  to  become  operational  under  NTDS, 
therefore,  the  following  steps  would  be  necessary:  1)  Additional 
testing  and  verification;  2)  modification  of  this  version  to 
accomodate  the  DMR  hardware  feature;  3)  the  preparation  of  the 
system  documentation,  and  4)  the  acceptance,  tailoring,  and 
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dissemination  of  the  program  by  FCDSSA.  While  the  first 
three  of  these  steps  could  proceed  in  parallel  to -at  least 
some  degree,  it  is  estimated  that  24  to  30  months  would 
elapse  if  this  mode  of  operation  were  to  be  implemented,  and 
alternate  approaches  must  be  considered. 

One  possible  modification  of  the  above  approach  would  be 
to  operate  SIMAS  on  the  Q-20/642B  hardware  of  NTDS,  but  divorced 
from  NTDS/FCDSSA  operations;  i.e.,  in  a  stand-alone  mode. 

This  would  require  the  removal  of  one  computer  from  the  NTDS 
configuration  for  exclusive  use  by  SIMAS.  In  order  to  do  this, 
NTDS  itself  must  be  shut  down  to  make  the  initial  change-over, 
restarted  to  work  in  a  mode  of  degraded  capability,  shut  down 
again  when  SIMAS  is  no  longer  required,  and,  finally  restarted 
in  the  fully  operational  mode.  Theoretically,  each  shutdown 
and  restart  of  NTDS  should  take  anywhere  from  one  to  thfee 
minutes.  However,  NTDS  maintains  a  rather  large  data  base  that 
is  continually  being  updated;  this  data  base  is  lost  on  system 
shutdown,  and,  after  restart,  approximately  15  minutes  is 
required  to  reconstitute  the  complete  data  base.  When  the 
effects  of  this  degradation  are  compounded  with  the  reduced 
capability  of  a  system  with  a  central  processor  removed,  it  is 
clear  that  the  operation  of  NTDS  would  be  seriously  impaired, 
and  it  appears  unlikely  that  shipboard  personnel  would  elect  to 
execute  SIMAS  under  such  circumstances. 
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Apart  from  these  considerations,  Q-20  program  verification 
must  be  accomplished;  documentation  (though  not  as  extensive  as 
required  by  FCDSSA)  must  be  prepared;  and  some  group  other  than 

FCDSSA  found  to  assume  responsibility  for  on-board  installation 
and  maintenance  of  the  model.  It  is  estimated  that  at  least 
12-15  months  would  be  required  if  this  mode  of  operation  were 
to  be  adopted. 

A  third  approach  which  might  be  pursued  would  involve  the 
operation  of  SIMAS  as  a  part  of  the  ICAPS  (Q-20/642  hardware) 
system.  This  would  restrict  the  program  to  carrier  operation, 
as  only  those  ships  will  have  this  type  of  instllation,  but 
perhaps  this  environment  would  provide  valuable  information  as 
to  the  operational  utility  of  SIMAS.  Since  the  Q-20  version 
was  not  designed  to  operate  under  the  SYMON  monitor,  and  since 
other  ICAPS  programs  are  written  in  FORTRAN,  it  would  be 
appropriate  to  modify  the  1108  (FORTRAN)  version  of  SIMAS  for 
this  application,  and  to  take  advantage  of  the  ICAPS  environ¬ 
mental  section  as  well.  Other  considerations  for  this  mode  are 
similar  to  those  of  the  NTDS  stand-alone  mode.  This  approach 
could  be  implemented  in  about  4  months. 

The  only  other  alternative  with  any  significant  probability 
of  success  is  that  of  direct  adoption  of  the  PDP-11  version 
for  stand-alone  shipboard  use.  This  approach  has  the  obvious 
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advantage  of  starting  with  software  which  already,  incorporates 
background  noise  monitoring  capability  and  which  need  not  be 
modified  for  compatibility  with  any  existing  monitor  program. 

On  the  other  hand,  however,  it  would  require  the  addition  of  new 
non-standard  mini-computer  and  interface  equipment  to  the 
existing  shipboard  environment.  The  obstacles  to  be  overcome 
here  are  difficult  to  estimate,  but  would  probably  be  severe; 
even  if  authorization  could  be  obtained  quickly,  procurement 
and  other  procedural  delays  would  probably  stretch  the  develop¬ 
ment  time  to  as  long  as  several  years. 

It  is  to  be  noted  that  only  the  last  of  the  above  approaches 
provides  the  background  noise  monitoring  feature.  The  motiva¬ 
tion  for  implementation  of  this  feature  was  largely  that  of  a 
feasibility  study.  Noise  monitoring  was  only  tested  in  a  small 
number  of  cases  and  only  in  bottom  bounce  mode.  Before  this 
feature  could  be  considered  operational,  even  on  the  PDP-11, 
there  would  have  to  be  a  great  deal  more  testing.  In  addition, 
installation  of  this  capability  in  any  shipboard  situation  would 
require  selection  and  procurement  of  the  necessary  hardware 
to  capture  and  convert  the  noise  signals  for  use  by  the  computer. 
Furthermore,  to  incorporate  this  feature  in  any  but  the  PDP-11 
versions  of  SIMAS,  it  would  be  necessary  to  write  the  noise 
monitoring  program  in  the  appropriate  language  for  execution 
under  the  host  computer’s  operating  system.  Even  though  the 


VI-5 


PDP-11  version  could  be  used  as  a  guide  in  this  operation, 
writing  and  fully  testing  this  feature  would  probably  require  6 
months,  at  least  three  of  which  would  have  to  be  after  the 
appropriate  analog-to-digital  conversion  hardware  was  available. 

In  summary,  then,  it  appears  that  within  NTDS  there 
are  in  fact  no  alternatives  which  would  permit  the  attainment 
of  an  on-board  SIMAS  capability  in  less  than  a  year.,  and  even 
under  the  best  of  circumstances  would  result  in  inconvenient, 
awkward,  or  otherwise  unacceptable  modes  of  operation.  Only  if 
an  extra  Q-20  computer  is  available  outside  of  the  NTDS  system 
can  an  at-sea  SIMAS  capability  be  achieved  within  6  months. 

It  must  be  emphasized  that  this  fact  in  no  way  reflects  on  the 
technical  capabilities  either  of  SIMAS  itself  or  of  its 
developers,  but  rather  is  to  be  expected  whenever  an  attempt 
is  made  to  merge  a  new  computer-based  capability  into  an 
existing  environment  which  did  not  foresee  the  addition  of  such 
capability  in  the  early  design  stages.  For  the  future,  such 
difficulties  can  be  avoided  only  by  planning  now  for  direct 
implementation  of  the  features  of  SIMAS  into  the  new  digital 
sonar  systems  which  will  be  appearing  in  the  fleet  in  the 
next  five  to  ten  years. 
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DEPARTMENT  OF  THE  NAVY 
OFFICE  OF  NAVAL  RESEARCH 
ACOUSTIC  ENVIRONMENTAL  SUPPORT  DETACHMENT 
ARLINGTON,  VIRGINIA  22217 


in  tjitf  ICift  TO 

AESD:PRT:dod 
20  September  1973 


MEMORANDUM  FOR  MR.  FRED  BRUMBAUGH,  PMS-3026 
Subj:  FLIT  Program 

1.  On  Thursday,  19  July,  I  visited  Raytheon  with  Mr.  C.  W.  Spofford 
of  my  staff  and  Dr.  Morenoff  and  Mr.  Baker  of  Ocean  Data  Systems,  Inc. 

The  purpose  of  the  visit  was  to  review  both  the  physics  and  the  pro¬ 
grammatic  implementation  of  the  FLIT  model.  At  Raytheon  we  met  with 
Mr.  Tom  Russell  and  Mr.  Jerry  Bradshaw  of  Raytheon;  Mr.  Dick  D'Urso  of 
NUSC  Newport,  and  Mr.  Barry  Chapmar  from  NAVSHIPS. 

2.  We  were  not  briefed  on  the  purpose  of  the  FLIT  system.  We  were  told 
that  it  was  too  highly  classified;  the  discussions  were  confined  to  the 
ray-tracing  sub-mode  of  the  system. 

3.  Apparently,  the  ray-trace  propagation  loss  model  developed  by  Mr. 
William  Barry  of  NUSC  Newport  had  been  provided  to  Raytheon  for  imple¬ 
mentation  on  a  16-bit  computer.  Raytheon  had  essentially  no  freedom  in 
the  selection  of  physics  to  be  implemented,  rather  their  task  was  to 
implement  the  highest  possible  speed  ray-trace  in  an  interactive  mode 
on  this  mini -computer.  The  system  as  we  saw  it  demonstrated  accepts  as 
input  from  the  operator  either  the  sound  speed  profile  from  the  surface 
to  the  bottom  or  a  given  BT  profile.  If  given  a  sound  speed  profile, 
the  operator  can  display  the  given  profile  on  a  CRT  display  and  then 
make  modification  to  this  profile  until  the  displayed  profile  meets  with 
the  operators  satisfaction.  If  given  a  BT  profile,  which  only  extends 
to  rather  shallow  depth,  the  program  assumes  the  gradient  of  temperature 
to  be  a  constant  until  it  reaches  the  bottom  temperature  and  then  iso¬ 
thermal  to  the  bottom.  It  then  assumes  at  present  a  salinity  of  35  ppt 
and  uses  Leroy's  equation  for  the  computation  of  sound  speed.  With  the 
sound  speed  profile  established,  the  system  computes  a  fan  of  rays  for 
particular  parameters  of  source  depth,  maximum  range,  angle  of  tilt  and 
beam  width  which  are  all  under  operator  control.  The  ray  tracing  is 
very  high  speed,  and  the  display  almost  continuously  changes  as  the 
operator  changes  one  of  these  four  input  specifications.  At  some  future 
point  in  time,  the  system  will  also  compute  the  propagation  loss  along  each 
of  the  rays,  and  display  the  rays  on  the  CRT  display  in  a  two-tone  bright¬ 
ness  display.  The  rays  will  be  brighter  when  the  loss  along  the  ray  does 
not  exceed  an  operator  controlled  figure  of  merit,  and  less  bright  after 
that  figure  of  merit  is  exceeded.  This  binary  representation  of  propaga¬ 
tion  loss  is  less  than  optimum  in  that  it  essentially  displays  only  the 
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fifty  percent  probability  detection  contour.  With  the  given  display 
facilities.  It  should  be  possible  to  present  contours  In  range  and  depth 
-of- propagation  loss;-  Since  the  algorithms  for  the  computation  of  trans¬ 
mission  loss  along  an  Individual  ray  were  neither  developed  by  the 
Raytheon  team  nor  implemented  yet  In  the  FLIT  system,  no  detailed  dis¬ 
cussion  of  these  techniques  was  appropriate.  One  minor  point  worthy  of 
comment,  however.  Is  that  the  loss  at  the  bottom,  as  It  will  be  Imple¬ 
mented,  is  at  present  independent  of  frequency. 

4.  From  a  software  point  of  view,  the  system  has  been  extremely  well 
implemented.  Some  sophisticated  programming,  as  well  as  good  solid 
numerical  analysis  has  been  done  and  very  effective  use  has  been  made 
of  software  people  who  are  also  well  aware  of  hardware  capabilities. 
Extremely  effective  use  has  been  made  of  existing  display  hardware  cap¬ 
ability.  The  sophisticated  numerical  analysis  which  has  been  done  might 
be  transferable  to  another  configuration,  but  the  detailed  programming 
probably  cannot.  Implementation  on  another  machine  or  for  a  different 
display  system  could  well  take  an  equivalent  or  greater  amount  of  develop¬ 
ment  time.  Present  implementation  proves,  once  again,  that  special  pur¬ 
pose  highly  constrained  systems  are  much  more  efficient  than  any  general 
purpose  system,  but  they  are  hard  to  change,  expensive  to  build,  and  not 
easily  transferable.  Software  maintainence  would  be  difficult  to  perform 
outside  the  development  group  at  Raytheon.  For  example,  even  simple 
changes  like  changing  the  form  of  the  bottom  loss  equations  to  be  fre¬ 
quency  dependent  could  not  be  done  in  an  operating  environment. 

5.  In  summary  it  is  considered  that  the  group  at  Raytheon  has  done  an 
outstanding  job  of  implementing  the  specified  model  on  an  existing  mini¬ 
computer  and  specialized  display  system.  Any  more  detailed  critique  of 
the  physics  of  the  transmission  loss  package  incorporated  in  the  FLIT 
system  must  be  done  in  conjunction  with  the  model  developers  at  NUSC  Newport. 

(?•  glitz 

P.  R.  TATRO 

Copy  to: 

LCDR  T.  McCloskey,  LRAPP 
Dr.  Ed  Morenoff,  ODSI 
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